fix(node): save install settings in lock identity#9991
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces InstallManifest as a new source for tool options, allowing settings from the install manifest to be incorporated into the option resolution process. It also refactors the Node.js plugin to include additional build configurations, such as mirror_url and cflags, in the lockfile identity. Feedback identifies concerns regarding lockfile portability and stability in the Node.js plugin, specifically pointing out that platform-specific checks and direct environment variable access for build options can cause inconsistent lock identities across different systems.
Greptile SummaryThis PR expands the Node lockfile option identity to include all effective
Confidence Score: 5/5Safe to merge — the change is a lock-identity expansion that adds fields without removing existing ones, and the new test suite validates all key branches. The rewrite of resolve_lockfile_options is well-contained: it only produces a BTreeMap that feeds into the lock key, so the worst realistic outcome of a bug here is a stale lock reuse or spurious re-install — not data corruption or a security issue. Env-var fallbacks for all four source-build inputs are correctly captured. Default values are recorded rather than omitted, which is the right call for future-proofing. The existing unit tests cover the default path, binary-only path, and full source-build path. No files require special attention Important Files Changed
Reviews (10): Last reviewed commit: "fix(node): stabilize lock default settin..." | Re-trigger Greptile |
|
CI note: This comment was generated by an AI coding assistant. |
32762fe to
4a5da17
Compare
📝 WalkthroughWalkthroughresolve_lockfile_options now always builds lockfile options from ChangesNode Lockfile Options Refactoring
🎯 3 (Moderate) | ⏱️ ~20 minutes
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
CI note: the current failures appear unrelated to this PR. I checked another recent non-Node PR/test run ( This comment was generated by an AI coding assistant. |
Summary
node.*install settings in the Node lockfile option identitymirror_url,compile = auto,make,ninja = auto, andconcurrency = automise.lockwhile preserving the existing platform metadata[tools]options out of scope for this PRClassification
Lock identity / stale-lock invalidation fix.
node.*settings can change either the selected Node archive or the source-build inputs for the same Node version. Those settings need to be part of the exact lockfile option key so changing configuration does not reuse a lock entry created with different install inputs.Default Settings
Defaults are intentionally written to the lock identity when they are non-empty. This makes lockfiles stale if a future mise release changes a Node install default. Without recording defaults, an old lock entry created under one default could still match after the default changes, even though the effective install inputs are no longer the same.
Defaults that are host-dependent are recorded as stable markers instead of resolved local values. For example, unset Ninja mode is stored as
ninja = autoand unset source-build concurrency is stored asconcurrency = auto, so the lock identity captures the default behavior without depending on the current machine's PATH or CPU count.Source-build-only settings are recorded when source builds can be used (
compile = trueor the defaultautofallback path). Whencompile = false, source-build settings are not part of the effective install path and are omitted. Empty optional settings are also omitted to avoid meaningless lock keys.Env Fallback
The legacy env fallback is still required for lock identity because the Node installer still honors those variables during source builds (
NODE_BUILD_MIRROR_URL,NODE_CFLAGS,NODE_CONFIGURE_OPTS,NODE_MAKE_OPTS, andNODE_MAKE_INSTALL_OPTS). If lockfile option resolution ignored them, changing one of those env vars could reuse a lock entry produced for different source-build inputs.The
MISE_NODE_*env vars are covered through normalnode.*settings resolution.Verification
cargo fmt --checkgit diff --checkcargo test node_lockfile_optionsmise run rendercargo clippy -- -D warnings